If you do `derive(PartialEq)` on a packed struct, the output shown by
`-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST
nodes are constructed within the compiler. But it does mean anyone using
`-Zunpretty=expanded` output as a guide for hand-written impls could get
a nasty surprise.

This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```

…-note, r=estebank

Remove confusing 'while checking' note from opaque future type mismatches

Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.

For example:

```rust
note: while checking the return type of the `async fn`
  --> $DIR/dont-suggest-missing-await.rs:7:24
   |
LL | async fn make_u32() -> u32 {
   |                        ^^^ checked the `Output` of this `async fn`, found opaque type
```

We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!

r? ``@estebank`` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.

…joshtriplett

Add Style Guide rules for let-else statements

cc `@rust-lang/style` `@rust-lang/rustfmt`

[rendered](https://github.com/calebcartwright/rust/blob/c694d07c6413ba55caa10b9f8b853df7a7792e7c/src/doc/style-guide/src/statements.md#else-blocks-let-else-statements)

…r=RalfJung

Fix syntax in `-Zunpretty-expanded` output for derived `PartialEq`.

If you do `derive(PartialEq)` on a packed struct, the output shown by `-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST nodes are constructed within the compiler. But it does mean anyone using `-Zunpretty=expanded` output as a guide for hand-written impls could get a nasty surprise.

This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```

r? ``@RalfJung``

…s, r=notriddle

Inline CSS background images directly into the CSS

A nice advantage of this is that it removes a few entries in the list of static files.

r? ``@notriddle``

Add proc-macro boilerplate to crt-static test

I was seeing this failure when running ui tests with with a `-Cpanic=abort` stdlib targeting fuchsia:

```
---- [ui] tests/ui/proc-macro/crt-static.rs stdout ----
normalized stderr:
warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic

warning: 1 warning emitted

The actual stderr differed from the expected stderr.
```

`force-host` was enough to stop it from running/failing, not sure if I should also add `needs-unwind`?